List reversal: back into the frying pan

More than thirty years ago Rod Burstall showed how to do a proof of a neat little program, shown in a modern notation in figure 1(a) [4]. The program, which was well understood by programmers even before Burstall’s efforts, reverses the order of a straight-line linked list of cells in the heap using only three variables and without moving or copying anything in the heap. An algorithm which does copy cells in order to produce a separate reversed list, is shown in figure 1(b). A copying algorithm which doesn’t use assignment is shown in figure 1(c). Each of the algorithms has its advantages and disadvantages: reverse by copying means that you don’t disturb the original list and you have a separate copy to play with, but if you don’t need the original again it’s wasteful of time and space; copying without assignment is even more wasteful because it needs a stack of procedure executions, unless you have a compiler clever enough to recognise that it’s equivalent to the with-assignment version. Copying without assignment was historically the first to have a specification and a proof, then copying with assignment and finally in-place list reversal. The in-place reversal problem influenced early developments in separation logic, by showing us so clearly that separation was important [3]. A proof in separation logic is shown in figure 3, using the heap predicate listp defined in figure 2. Note that the predicate pins down the precise location in memory of the cells of the list as well as the values of the sequence that they represent, so that the proof can show that the reversed list uses exactly the cells of the original list with exactly their original value content. I concentrate on in-place reversal because it remains the most economical and the most ‘dangerous’ of the three algorithms, and because it has a useful peculiarity: it terminates even if the input list is circular, whereas the other two terminate only on finite straight-line lists. More peculiarly still, it terminates even if the input list has a handle and then a circle, a ‘frying pan’ list as in figure 4, which reads 1, 2, 3, 4, 5, 6, 7, 8, 4, 5, 6, ... It reverses the handle, then goes round the pan reversing it, then back up the handle de-reversing it, finishing up just where it started, so figure 4 ‘reversed’ reads 1, 2, 3, 8, 7, 6, 5, 4, 8, 7, 6, ... It works because the nil which it puts in y is inserted into the heap by [z + 1] := y, and so acts a termination marker when it’s seen again. The copying algorithms don’t change the original list, so they go round and round the pan for ever looking for a nil that isn’t there. 1 Proof of frying-pan ‘reversal’ The copying algorithms don’t work on the structure in figure 4 because it isn’t a list. Lists represent sequences, and sequences don’t have loops. To specify what the in-place list reversal algorithm does